setDebugging_

When does the Debug callback fire?

The following old thread got me wondering about debugging.

  • http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14629945&#14629945


I see that the callback function fires with parameters 'string' and 'int'

 

  • the 'int' parameter is the line number
  • the 'string' parameter is the name of the file
    • is "Line" when running from the DXL window
    • is a full name when running from a menu
    • is the exact included name when running from an include file, which is often relative.


Failing to "setDebugCallback_" the callback results in DOORS flying off into the weeds and needing to be aborted with task manager. (e.g. "Includes\IncFile.inc")

This sort of debugging doesn't seem to useful, unless

 

 

  • you want to follow execution and print the values of global variables.
  • the callback cleverly looks at file and line to determine when to start printing and when to stop; if for some reason you cannot setDebugging(true)/(false) in the code itself.

  

void clbkSetDebugging_(string NameFile, int LineNumber)
{  print "\tclbkSetDebugging_  line  " LineNumber " \tin file [" NameFile "]\n"
}
setDebugCallback_(clbkSetDebugging_)
setDebugging_(true)
 
Buffer buf = create()
buf = "1"
int i
string s = "A"
for (i=0; i<10; i++)
{  buf += s
   s = s s
}
clbkSetDebugging_("WTH, calling the callback directly to see what happens", -1)
delete(buf)
setDebugging_(false)


-Louie


llandale - Mon Aug 06 07:15:47 EDT 2012

Re: setDebugging_
Mathias Mamsch - Mon Aug 06 07:50:41 EDT 2012

The debugging callback will as far as I know before the execution of code lines, that contain executable statements, that means, for example NOT on comments, declarations, etc.. The debugging callback will be executing in its own DXL context (like a DXL Layout) so you can but must not try to access any global variables of your program. You can however access top level context variables which are always valid.

You are right, this debugging callback seems to be very useless for normal DXL programmers. However imagine the debugging callback will start communicating with an external debugger GUI - combined with the ability to get information about DOORS internals, like DXL contexts, stack, etc. IBM could use that for their own debugger. Since DOORS 9.3 interesting new perms are appearing, like:

void ::do (DebugVar&, Script__, void)

Which hints additionally that IBM is improving the DXL Debugging capabilities. Maybe that helps, regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: setDebugging_
llandale - Mon Aug 06 08:00:40 EDT 2012

Mathias Mamsch - Mon Aug 06 07:50:41 EDT 2012
The debugging callback will as far as I know before the execution of code lines, that contain executable statements, that means, for example NOT on comments, declarations, etc.. The debugging callback will be executing in its own DXL context (like a DXL Layout) so you can but must not try to access any global variables of your program. You can however access top level context variables which are always valid.

You are right, this debugging callback seems to be very useless for normal DXL programmers. However imagine the debugging callback will start communicating with an external debugger GUI - combined with the ability to get information about DOORS internals, like DXL contexts, stack, etc. IBM could use that for their own debugger. Since DOORS 9.3 interesting new perms are appearing, like:

void ::do (DebugVar&, Script__, void)

Which hints additionally that IBM is improving the DXL Debugging capabilities. Maybe that helps, regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

The first time I was playing with this the callback was firing only for function calls. Now it's firing two or more times per line of code; such as when inserting line 14 "s = s".